The present disclosure relates generally to call routing in telephony equipment, and relates more particularly to managing call routing at a call routing device that may include a relatively large number of call routing rules.
Calls that are placed through a communication network typically are connected after a call setup process. Part of the call setup process can include one or more determinations of how the call is to be directed or “routed” through the communication network. A communication network typically is composed of a number of nodes and may include pathways or routes that operate based on different telecommunication principles or protocols. A call that arrives at or leaves a communication network device while traversing a given route may be referred to respectively as an incoming call or an outgoing call. An incoming or an outgoing call is associated with “call information” that may be used to contribute to routing the incoming call as an outgoing call directed to a particular node in the communication network. The term “call information” is used herein to indicate information associated with the call, such as characteristics of the call and/or payload data or signaling information. Call characteristics may include items such as source or destination identifiers or other information that can assist in processing or routing the call. As used herein, the term “call” is meant to refer to any type of telecommunication messaging that can be carried on voice or data or other channels, including for example, payload or content data such as video, audio, image or text data, signaling information or a message waiting indication. Accordingly, the term “call” is used herein to indicate any type of information carried over a telecommunication network, including networks that may each operate based on different communication principles or protocols.
Specialized telephone provider networks have been used in communication networks that implemented time division multiplexing (TDM), analog, or other principles and methods for transmitting voice or data using traditional telephone networks. Implementations of these types of networks include circuit switched networks, such as the publicly switched telephone network (PSTN). More recently, packet switched networks such as internet protocol (IP) networks, such as the Internet, have been used to transport calls and some or all of such call information. For example, technologies such as Voice over Internet Protocol (VoIP) allow users to participate in telephone calls using Internet-based phones that connect through the Internet rather than through traditional telephone networks.
A call routing device, such as a communication gateway, may operate at the interface of two or more networks to route calls and call information and provide any needed conversions, such as converting from one communication protocol used on one network to a different communication protocol used on the other network. Such conversion is well known in the art. When a call is placed, a call connection process occurs to determine how the call should be routed and connected. The call routing device may determine how a call should be routed and connected by examining certain characteristics of the call and call information, such as the source or destination identifiers for the call. The call routing device may be provisioned with various information, including call routing algorithms to determine how the call should be routed and connected, based on such factors as a set of rules applied to the call and/or call information. Such a set of rules provided in the call routing device is often referred to as a dial plan or as a routing table configuration.
A routing table is a construct used by a call routing device such as a gateway to determine how to route incoming calls based on the contents of the routing table and one or more attributes of an incoming call. The call attributes may be determined from the call information, for example. Each of the entries of the routing table, such as a routing table row, is generally provided in the form of a rule. The rule generally is applied to match attributes of the call with a given rule matching criteria, and then to manipulate the call information as specified in the rule. This type of construct for a rule in a routing table can have certain limitations on the flexibility of managing the routing table.
Referring to FIG. 1, a schematic block diagram of a call router 100 is illustrated. Call router 100 is illustrated as a representation of a call routing device in the abstract. For example, call router 100 may be conceptualized as being implemented in hardware or software, and may be viewed as an apparatus or process implementing the disclosed systems and methods.
Call router 100 includes a routing engine 110 that is used to implement call routing in call router 100. Routing engine 110 includes call routing logic 120 and routing table 130, which operate together to perform call routing. Call routing logic 120 provides the logic and processing capability to make call routing determinations based on various criteria. A criteria used by call routing logic to make call routing determinations may be drawn from attributes of an incoming call 102 evaluated against an entry in routing table 130. The configuration of call routing logic 120 and routing table 130 is sometimes referred to as a dial plan. Routing engine 110 receives the input of incoming call information and provides the output of outgoing call information, which can be determined by routing logic 120 and routing table 130.
Routing engine 110 inspects attributes 104 of incoming call 102 and can manipulate attributes 104 in accordance with call routing logic 120. Routing engine 110 can be configured to be responsive to certain call attribute values. For example, routing engine 110 determines and manipulates the attributes of an outgoing call 112 in accordance with attribute values of incoming call 102, call routing logic 120 and an entry in routing table 130, often referred to as a “rule.” Routing table 130 in routing engine 110 may include a number of rules as row entries.
Call router 100 can be implemented as a gateway that translates between TDM and VoIP communication networks. With such an implementation, there can be additional challenges for ensuring robust and accurate call routing. In addition, a gateway operating as a call router represents a challenge with respect to administration of gateway configuration. In some instances, a gateway is specifically configured according to a user's needs for translating between a TDM network and a VoIP network. User demands for call routing configurations in a gateway dictate a design that has powerful and flexible administrative and call routing features, which have been a challenge to achieve with the known call routing and routing table configurations.
For example, user applications may implement call routing based on a relatively large number of call attributes. Examples of some of the call attributes that may be used in call routing are listed in Table 1 below.
TABLE 1Calling Party NumberCalled Party NumberCalling Party NameCalled Party NameRedirecting Party NumberDevice (e.g. T1/E1 span, analog port)Redirecting Party NameChannel within DeviceIP AddressType of Number (ISDN)Host NameNumbering Plan (ISDN)IP PortPresentation Indicator (ISDN)
Other types of information may be used to assist in determinations of call routing for a given call. For example, time of day, date or other environmental factors or data, including traffic flow, type of call (e.g. voice or facsimile) and cost considerations may be used to contribute to determining how a call is to be routed through the communication network. As an example of a routing operation, a call placed to an outside line in a telephone switch might implicate the rule “if the number dialed begins with a ‘9’, modify the call attributes to direct the call to an external trunk.” Such a rule would have an entry in routing table 130 indicating a call attribute of a first digit being a ‘9’ to match such a dialed number. The rule would include the action of connecting such a matched number with an external trunk, such as by creating/modifying the outgoing call attributes to include an identifier for the external trunk.
In FIG. 1, call router 100 has an incoming call connection 102 with attributes 104. Incoming call attributes 104 have values relating to the parameters of an interface, a call number, a called number, a device number and a channel. In the illustrated attributes 104, the interface parameter has a value of “TDM”, the calling number parameter has a value of 716-739-9003, the called number parameter has a value of 1-800-CAMERAS, the device number parameter has a value of 1 and the channel parameter has a value of 15. Attributes 104 are examined by call routing logic 120 in routing engine 110 to produce an outgoing call 112. While incoming call 102 has attributes 104 related to a TDM interface, outgoing call 112 has attributes 114 that relate to a VoIP interface. Accordingly, attributes 114 include parameters for an interface, a calling number, a called numbered, a called name and a host. Incoming call 102, as well as outgoing call 112, may have one or a number of associated parameters that may be selected by call routing logic 120 in routing engine 110 for determining call routing. Accordingly, attributes 104 are illustrative for a TDM interface, and attributes 114 are illustrative for a VoIP interface.
The parameter values of attributes 114 can be determined by routing engine 110 based on a set of rules in routing table 130, in conjunction with the parameter values of attributes 104. As shown by attributes 114, the listed parameters and parameter values may be particular to the interface through which a call is processed by call router 100. In the general case, incoming call 102 and outgoing call 112 may have one or more associated parameters, respectively, that are used for call routing in relation to interfaces (not show) available to call router 100.
A rule for routing incoming call 102 that is implemented in call router 100 may have a matched criteria for call attributes 104 of: interface=TDM; called number=1-800-CAMERAS. When incoming call 102 matches this example rule criteria, as indicated by parameter values in attributes 104 being matched to an entry in routing table 130, the rule is applied to produce attributes 114 of outgoing call 112. The resulting operation by call router 100 to create/modify attributes 114 for outgoing call 112 may include: an action to set the interface parameter value to VoIP; maintain the calling number parameter value; change the called number to 101; and set the host address to “buffalo.xyz.com.” The particular rule in this case is found (matched) in routing table 130.
Referring now to FIG. 2, the above described operations for routing a call depend on resources (not shown) within call router 100 to store rules in a routing table 200 that can be searched, matched and applied to incoming call 102 to provide a mechanism for customizing call routing for outgoing call 112. Thus, routing table 200 can represent an implementation of routing table 130 in routing engine 110 of FIG. 1. The entries in routing table 200 are typically configured and entered by an administrator to obtain a desired set of rules for call routing. Due to the nature of how routing table 200 is configured and used in call routing, an administrator may spend a significant amount of time entering routing table rules for each desired routing operation based on incoming and outgoing call attributes 104, 114. In addition, the administrator may prefer to test the routing table entries before committing the rules to active operation in call router 100. The time expended in entering, testing and maintaining routing table entries may increase dramatically when a large number of call attributes 104, 114 are used to make determinations for call routing. Such a large number of call attributes 104, 114 that are tested by a given set of rules in routing table 200 may result in a large number of rules, in some cases larger than that which can be easily supported or maintained using the resources available in the system in which call router 100 is implemented.
FIG. 2 shows how a relatively large number of routing table entries in comparison to available resources (including administrative entering, testing and maintenance) can result from even a relatively small number of incoming call attributes 104 being examined for rule matching and call routing. Routing table 200 is illustrated with a number of rows representing call routing rules 220-226. Each of rules 220-226 is illustrated as including incoming call attributes 210 that are matched against incoming call attributes 104 to determine which rule(s) to apply for call routing of incoming call 102. Each of rules 220-226 that occupies a row in routing table 200 includes a set of outgoing call attributes 230 to be applied to provide call routing. Outgoing call attributes 230 are selected based on which rule out of rules 220-226 is matched to incoming call 102.
Rules 220-226 can represent a portion of rules for call routing used by a company XYZ. Company XYZ may, for example, wish to take incoming calls from a traditional telephone network, and route the calls to operators on various VoIP networks. The XYZ company may have set up several servers in different cities to provide a facility for operators to answer calls routed to each server. In routing table 200, an attribute column 206 provides a host parameter for URL entries for the different host cities, namely, Buffalo, Syracuse and New York. An attribute column 205 provides an identifier parameter for a particular product of XYZ company to further direct incoming calls. Call routing may be provided by producing, for example, a final URL used to route an incoming call. The called identifier can have a product name as the called name used in conjunction with the host URL, such as CAMERAS @buffalo.xyz.com, as can be indicated by rule 220 of routing table 200.
Routing table 200 is used to indicate an incoming area code parameter, such as 716, 315 or 212 as shown in an attribute column 202, that can be used to match an area code of an incoming call to determine a corresponding host parameter address for the call from attribute column 206. The called number parameter entry in attribute column 203 may also be used to determine a corresponding called name parameter value from attribute column 205.
As shown, routing table 200 is configured to support three area codes (716, 315 and 212), three products (cameras, radios and monitors) and three cities (Buffalo, Syracuse and New York) for call routing purposes. The methodology involved in using routing table 200 to contribute to routing a call would result in nine rules (3×3) that would be entered, and preferably tested, to permit the router to support the entire set of permutations for area codes of incoming calls, cities in which servers are located and the different products of company XYZ.
A drawback to an approach of using the methodology of call routing rules in accordance with routing table 200 is seen when additional area codes, products or cities are to be added to routing table 200. For example, if a new product is added, a new rule for the product is added to routing table 200 for each area code or for each city. In the example given above, if there were ten products and ten area codes or cities, the addition of a product represents an additional ten call routing rule entries in call routing table 200, one for each of the ten such area codes or cities. Such a modification to routing table 200 can be cumbersome and difficult to administer, and it can reduce or eliminate the available resources for further entries in routing table 200.
In practice, the call routing table has a limited capacity for the number of rules that can be defined. Therefore, as more rules or parameter additions are desired, the call router may not have the resources to implement additional rules that are desired to cover parameter permutations. In addition, management of the entries in the routing table can represent a significant burden on an administrator in terms of an amount of time used to enter and test the various permutations of rules or parameters.